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SUMMARY 


Computer-based  collaboration  between  geographically  dispersed  users  is  still  lim¬ 
ited  primarily  to  electronic  mail  and  file  transfer,  but  there  is  increasing  interest  in 
computer  support  for  real-time  interaction  between  remote  users.  The  problem  of 
implementing  remotely  shared  workspaces,  which  allow  users  to  operate  simulta¬ 
neously  on  the  same  objects,  is  of  broad  interest.  Our  objective  is  to  show  textual 

r  ’ 

workspaces  that  allow  real-time  collaboration  can  be  implemented  efficiently  by 
using  existing  operating  systems  and  communications  primitives.  This  paper  doc- 
uments  our  experiences  in  implementing  a  prototype  under  Berkeley  UNIX1,  using 
the  programming  language  C,  and  Berkeley  Interprocess  Communication  facilities. 
We  describe  design  alternatives  that  take  into  account  the  communications  band¬ 
width  between  the  different  sites  of  the  network,  and  we  introduce  an  efficient 

protocol  that  regulates  user  access  to  the  shared  workspace.  ,-t^l 
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REMOTELY  SHARED  WORKSPACES:  PROBLEM  AND  APPROACHES 

In  everyday  life  individuals  meet  to  review  and  edit  documents  that  include  text 
and  pictures.  The  main  objective  of  our  work  is  to  provide  usable  low-cost  alterna¬ 
tives  to  physical  meetings  held  for  the  purpose  of  editing  and  reviewing  documents. 
Every  participant  in  this  ‘Virtual”  meeting  has  in  front  of  him  a  workspace  where 
he  can  operate  on  the  same  objects  that  other  participants  see  in  their  workspace. 
Just  as  a  conference  telephone  call  provides  a  shared  “audio”  space  to  the  partic¬ 
ipants,  the  systems  we  are  describing  provide  a  shared  “visual”  workspace.  Even 
if  the  quality  of  human  interaction  is  not  as  high  in  the  remote  virtual  meeting  as 
it  is  in  the  physical  meeting,  as  long  as  it  is  above  some  threshold  of  acceptability, 
economic  considerations  may  well  favor  a  remote  meeting.  With  the  proliferar 
tion  of  high  bandwidth  computer  networks,  and  the  increasing  popularity  and 
affordability  of  powerful  workstations,  it  is  feasible  to  provide  the  users  with  the 
environment  and  the  tools  to  achieve  this  goal. 

Today,  computer-based  collaboration  between  geographically  dispersed  users 
is  still  limited  primarily  to  electronic  mail  and  file  transfer,  but  several  research 
groups  experiment  with  more  powerful  computer  support  for  team  work^’^.  Let 
us  summarize  the  features  of  some  of  the  prototypes  described  in  the  literature. 

At  the  MIT  Laboratory  of  Computer  Science,  users  share  information  from 
their  personal  calendars  to  schedule  meetings  using  a  real-time  conferencing  sys¬ 
tem,  RTCAL*.  Participants  speak  to  each  other  over  the  phone  and  use  their 
workstation  display  as  a  blackboard.  Another  system,  CES,  is  a  collaborative 
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editing  system  for  co-authors  working  asynchronously  on  a  shared  structured  doc¬ 
ument,  where  users  can  work  independently  on  separate  sections  of  the  document^. 

At  the  Xerox  PARC  Intelligent  Systems  Laboratory,  an  experimental  meet¬ 
ing  room,  Colab,  provides  computational  support  for  collaboration  in  face-to-face 
meetings.  Several  prototype  collaboration  systems  have  been  built  using  Colab, 
such  as  WYSIWIS  (What  you  see  is  what  I  see)  which  is  a  multiuser  interface  that 
expresses  many  of  the  characteristics  of  a  chalkboard  in  face  to  face  meetings®’^. 

At  IBM,  an  asynchronous  conference  system  has  been  implemented  for  Bit- 
net  and  Vnet®.  It  is  not  based  on  real-time  interaction,  users  send  and  receive 
information  at  their  own  convenience.  At  Stanford,  an  experimental  multimedia 
conferencing  facility  has  been  implemented  using  the  V-system,  a  message-based 
distributed  operating  system®. 

In  summary,  research  on  computer  support  for  people  working  together  simul¬ 
taneously,  where  real-time  interaction  is  essential,  is  still  in  its  beginnings.  Most 
work  is  based  on  experimental  systems  that  exist  only  in  one  laboratory.  In  con¬ 
trast  to  the  prevailing  trend,  our  objective  is  to  build  usable,  low-cost  remotely 
shared  workspaces  based  on  widely  available  systems  and  single-user  applications 
programs,  in  order  to  allow  a  large  user  community  to  experiment  with  this  new 
technology  of  real-time  collaboration.  Our  approach  differs  from  other  collabora¬ 
tive  tools  in  that  we  offer  a  general  purpose  utility  that  converts  any  single-user 
tool  into  one  that  can  be  used  for  real-time  collaboration  among  several  remote 
users. 

This  paper  documents  our  experience  in  constructing  a  prototype  for  remotely 
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shared  textual  workspaces,  with  the  intent  to  demonstrate  the  feasibility  of  im¬ 
plementing  such  a  system  quickly  using  widely  available  software  and  hardware 
resources.  We  use  the  C  programming  language  and  the  UNIX  system  calls  avail¬ 
able  under  the  4.3  version  of  Berkeley.  The  users  interact  with  the  system  using  a 
software  tool  such  as  a  text  editor,  the  only  learning  overhead  is  that  of  mastering 
a  few  simple  commands  for  session  control. 

The  paper  is  organized  as  follows.  We  start  by  comparing  two  alternative 
system  designs;  present  details  of  a  protocol  for  regulating  user  access  to  the 
shared  workspace;  describe  the  user  interface  and  the  prototype  implementation. 
We  conclude  with  open  issues  and  an  outline  of  our  future  goals. 
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DESIGN  ALTERNATIVES 

Fig.  1  depicts  a  collaborative  session  between  several  users  that  share  and  operate 
simultaneously  on  “objects”  contained  in  a  “workspace”.  Examples  of  objects 
are  text  files,  graphs,  or  images.  A  workspace  is  a  container  for  objects:  a  data 
management  system  for  creating,  accessing,  and  displaying  objects.  The  basic 
mode  of  operation  is  what  you  see  is  what  I  see:  ail  participants  have  identical 
views  of  the  objects.  Users  manipulate  objects  using  “tools”,  i.e.  single-user 
application  programs  that  can  be  used  to  operate  on  the  objects.  For  example, 
a  text  editor  is  an  appropriate  tool  for  text  file  objects.  The  basic  entities  of 
our  model:  users,  objects  and  tools,  may  reside  at  arbitrary  sites  of  a  computer 
network.  We  have  implemented  a  prototype  system  of  remote  shared  workspaces 
where  objects  are  restricted  to  be  text  files,  and  tools  can  only  accept  input  from 
keyboards.  For  such  “textual  workspaces” ,  participants  may  use  different  types  of 
terminals  or  woikstations. 

If  two  or  more  participants  can  issue  commands  simultaneously,  serious  prob¬ 
lems  may  occur.  For  example,  assume  a  text  editor  like  in  is  used  to  edit  a  text 
file  that  contains  the  line: 

....  the  boy  boy  ran  f  ast  .... 

If  two  users  simultaneously  issue  the  “dw”  command  to  delete  the  duplicate  word, 
we  end  up  with: 

....  the  ran  fast  .... 

To  make  sure  that  at  any  one  time,  only  one  user  can  issue  commands  (the  “ac- 


tive  user” ) ,  we  introduce  the  synchronization  concept  of  a  token:  the  tool  accepts 
input  only  from  the  active  user,  the  one  who  currently  holds  the  token.  The  to¬ 
ken  circulates  between  the  participants  according  to  a  fair  and  efficient  protocol 
described  in  the  next  section. 

In  addition  to  joint  manipulation  of  objects,  participants  need  to  manage  a 
session  (creating  it,  selecting  objects,  joining  and  leaving  a  session,  etc.).  Thus  it 
is  natural  to  introduce  two  windows:  a  “tool  window”  Wt  for  input  and  output 
from  the  tool,  and  a  “control  window”  We  for  session  management,  including  token 
control.  Windows  can  be  created  using  any  available  window  management  system 
such  as  the  Berkeley  UNIX  4.3BSD  window  program  that  runs  on  any  ASCII 
terminal,  or  the  MIT  X-windowa  that  runs  on  a  variety  of  workstations  including 
SUNs  and  DEC  VAXs. 

Participants  should  be  able  to  discuss  what  is  being  displayed  on  their  screen. 
An  intensive  discussion  may  require  a  telephone  conference  call,  but  occasional 
comments  and  questions  can  be  exchanged  via  the  control  window  We,  which 
doubles  as  a  “talk  window”. 

For  terminals  with  different  physical  characteristics,  users  should  be  aware 
that  the  terminal  with  the  smallest  tool  window  determines  what  operations  can 
be  followed  conveniently  by  all  users.  All  participants  define  a  tool  window  Wt 
with  the  same  number  of  lines  and  characters  per  line.  No  inconvenience  results 
from  control  windows  We  of  different  sizes. 

Thus  far  we  have  discussed  the  functional  design  of  the  system:  users  see  a 
single  shared  workspace  through  the  windows  on  their  terminal.  Possible  imple- 


mentations  of  this  design  differ  according  to  the  degree  of  (de-)centralization  and 
replication  of  the  physical  storage  of  the  workspace  objects  and  of  the  executable 
code  for  the  tool.  Among  many  alternatives,  we  have  implemented  two  designs 
that  appear  to  be  most  natural. 

Fig.  2  shows  a  centralized  implementation  of  workspace  and  tool.  Every  par¬ 
ticipant  is  represented  by  a  “user  agent”  process  Ptt  that  handles  both  his  tool 
window  and  his  control  window  (merges  input  from  the  windows  and  distributes 
output  to  them).  The  centralized  data  and  processes  may  reside  on  a  separate 
computer  or  on  one  of  the  participant  machines.  Fig.  3  shows  a  replicated  imple¬ 
mentation  where  every  participant  has  his  own  copy  of  workspace  and  tool.  This 
makes  sense  when  each  participant  runs  on  a  separate  computer. 

In  both  figures,  processes  P*  called  the  session  server  process  is  connected 
to  all  Pu  processes  (we  choose  ***  as  a  superscript  of  P,  since  the  process  is  di¬ 
rectly  connected  to  other  processes  in  a  “star”  like  topology).  The  following  is  a 
description  of  the  major  functions  performed  by  Ptt  and  P*  in  each  approach: 

In  the  centralized  model  of  Fig.  2,  process  Pu  accepts  input  typed  by  the  active 
user  in  the  tool  window  Wt  and  sends  it  to  P*  which  forwards  it  the  tool  process. 
Process  P*  reads  the  output  generated  from  the  tool  process  and  send  it  to  all  Pu 
processes  for  display  in  Wt.  In  this  model,  we  assume  a  high  bandwidth  between 
the  session  server  process  P*  and  the  participant  sites  in  order  to  carry  out  the 
usually  large  volume  of  data  generated  by  the  tool. 

If  the  bandwidth  is  not  sufficient  to  provide  a  reasonable  response  time,  then 
we  may  use  the  replicated  model  shown  in  Fig.  3.  In  this  model,  process  Pu 


reads  the  input  typed  in  window  Wt  by  the  active  user  and  sends  it  to  process 
P*,  which  in  turn  broadcast  it  to  every  Pu  connected  to  it.  Upon  receiving  the 
input,  Pu  forwards  it  to  the  local  tool  process.  Thus  every  input  typed  by  the 
active  user  is  given  to  every  tool  process  via  P*.  The  voluminous  output  from 
the  tool  is  displayed  locally  at  each  site.  Therefore  in  the  replicated  model,  only 
the  “keystrokes”  need  to  travel  through  the  network.  This  may  lead  to  better 
response  for  remote  users  connected  to  the  session  with  low  bandwidth  channels. 
At  the  begining  of  the  session  a  copy  of  the  original  workspace  objects  is  sent  to 
each  participant,  and  at  the  end  of  the  session  all  copies  are  deleted;  only  the 
workspace  objects  at  the  “session  creator”  site  is  retained.  A  major  challenge 
of  this  approach  is  to  keep  all  workspaces  mutually  consistent  throughout  the 
duration  of  the  session. 

Input  to  the  control  window  We  is  handled  in  the  same  way  in  both  models. 
Process  Pu  receives  the  input  of  any  user  (not  only  the  active  user)  and  process  it 
according  to  its  type,  e.g.,  if  it  is  a  token  control  command,  appropriate  messages 
are  send  to  P*  and  to  the  control  window  We.  In  the  next  two  sections  we  describe 
in  details  the  protocols  and  procedures  for  dealing  with  We  input. 


TOKEN  MANAGEMENT  PROTOCOL 


How  can  users  share  access  to  the  tool  efficiently  and  fairly?  For  effective  work,  the 
active  user  must  be  guaranteed  an  uninterrupted  quantum  of  time,  Q ,  once  he 
gets  the  token.  For  fairness,  other  participants  must  be  able  to  request  the  token 
and  obtain  it  within  a  certain  known  waiting  time.  When  the  active  user  has  to 
release  the  token,  he  is  given  a  brief  grace  period,  G,  to  complete  his  current  task. 
Values  for  Q  and  G  can  be  set  when  a  session  is  created,  depending  on  the  tool 
and  the  number  of  users.  Current  default  values  axe:  Q  —  30  seconds,  G  =  5 
seconds.  Three  token  management  commands: 

GET-TOKEN .  RELEASE-TOKEN  and  FIND-STATUS 
are  entered  by  typing  CTRL-G .  CTRL-R,  and  CTRL-F,  respectively,  in  the  control 
window  We,  where  system  responses  are  displayed. 

GET-TOKEN :  The  system  will  react  to  the  requesting  user  ( “R-user” )  as  follows: 

1.  If  the  token  is  free,  the  R-user  gets  it  and  given  the  message  : 

You  have  the  token 
All  other  participants  receive  the  message: 

R-user  has  the  token 

2.  If  the  token  is  being  held  by  another  user  (the  “active  user”),  the  fol¬ 
lowing  message  is  sent  to  the  R-user: 

please  wait 

The  request  is  inserted  into  a  FIFO  “token  queue”  maintained  by  the 
session  server  P*.  When  the  token  becomes  available,  it  is  given  to  the 


user  at  the  head  of  the  queue.  If  the  queue  is  non-empty  the  message: 

please  release  the  token  within  Q  seconds 
is  sent  to  the  active  user.  If  the  active  user  does  not  release  the  token 
after  Q  seconds,  he  is  sent  the  message 

token  will  be  seized  in  G  seconds 
if  the  token  is  not  released  by  the  end  of  the  grace  period,  the  user  is 
given  the  message: 

time  expired,  token  seized 

3.  If  the  R-user  is  waiting  in  the  token  queue,  he  will  get  the  message: 
please  be  patient 

RELEASE-TOKEN:  If  issued  by  the  active  user,  makes  him  inactive.  If  issued  by  a 
user  waiting  in  the  token  queue,  deletes  his  entry  from  the  queue.  If  the 
queue  becomes  empty  after  deletion,  then  the  “release  token"  message 
is  retracted  by  displaying: 

token  request  canceled,  you  may  continue 

FIND_STATUS:  The  active  user  name  and  the  queue  status  are  displayed. 

Fig.  4  shows  the  state  diagram  for  a  user  process  Pu  with  respect  to  the  token. 
Transitions  from  one  state  to  another  depend:  on  the  clock,  on  token  management 
commands  entered  by  the  user,  and  on  messages  received  from  the  server  process 
P*  •  Each  transition  is  labeled  by  a  pair  event/ action.  An  event  is  either  a  user 
input  in  Wet  an  expired  time,  or  a  message  received  from  P*.  An  action  is  either 
a  message  send  to  P*  or  a  message  displayed  in  We. 


USER  INTERFACE  AND  PROTOTYPE  IMPLEMENTATION 


To  use  our  system,  one  user  (called  the  “session  creator”)  initiates  a  session  by 
typing: 

%  create-session 

This  creates  the  session  server  process  P *  which  prompts  the  user  to  provide  the 
following  information: 

•  participant  names:  the  login  names  of  all  participants, 
e.g.,  wahab  guan  jn 

•  object  names:  the  file  names  to  be  included  in  the  workspace, 
e.g.,  intro,  seel,  append 

•  tool  name:  the  tool  name  to  be  used  during  the  session 
e.g.,  vi 

•  model  type:  specify  whether  a  “centralized”  or  “replicated”  model  will  be 
used. 

P *  then  displays  an  integer,  the  sesston-td,  to  be  used  by  all  participants  in  es¬ 
tablishing  connections  with  P*.  Note  that  the  session-id  is  needed  since  there 
may  be  more  than  one  concurrent  session  on  the  machine  running  P*,  and  partic¬ 
ipants  need  to  identify  the  session(s)  they  wish  to  join.  Process  P*  waits  for  all 
participants  to  be  connected  and  join  the  session. 

To  join  a  session,  a  user  must  be  on  the  participant  list,  otherwise  any  attempt 
to  join  the  session  is  rejected  by  P* .  Each  user  creates  the  two  windows  Wt  and  We, 
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using  the  Berkeley  4.3BSD  window  program  (or  any  other  window  management 
system) . 

For  each  window  there  must  be  an  active  process  that  reads  input  typed  in 
the  window  and  send  it  to  the  user-agent  process  Pu,  and  displays  the  messages 
directed  to  the  window  by  Pu  as  shown  in  Fig  5  (a).  In  our  implementation,  in 
order  to  save  one  process,  we  decided  to  let  process  Pu  runs  in  window  Wt  as 
shown  in  Fig.  5(b).  In  the  following  we  refer  to  process  Pe  running  in  the  control 
window  We  as  the  “chat”  process. 

The  user  creates  process  Pu  in  the  tool  window  Wt  by  typing: 

%  user-agent 

Pu  asks  the  user  to  provide  the  following  information: 

•  host  name:  the  name  of  the  machine  where  P*  is  running 

•  session-id:  the  session-id  displayed  by  P*  when  it  started. 

Process  Ptt  displays  an  integer  called  port-id  and  waits  for  a  connection  by  Pe. 
Switching  to  the  control  window  We ,  the  user  types  the  command: 

X  chat  port-id 

where  port-id  is  the  number  displayed  by  Pu  in  window  Wt.  This  creates  process  Pe 
and  uses  the  port-id  to  establish  a  connection  with  Pu.  Soon  after  this  connection 
is  established,  process  Pu  is  connected  to  P*  using  its  host  name  and  session-id. 

When  all  participants  on  the  list  have  been  connected,  process  P*  informs  each 
process  Pu  about  the  mode  of  operation:  central  or  replicated.  In  central  mode, 
P*  creates  the  tool  process  (see  Fig.2),  while  in  the  replicated  mode,  P*  sends  a 
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copy  of  the  workspace  objects  to  each  participant,  and  each  participant  runs  his 
own  tool  process  (see  Fig.  3). 

When  the  session  starts,  the  active  participant  uses  window  Wt  to  interact  with 
the  tool  in  the  way  described  in  the  tool  manual,  as  if  the  active  user  were  the 
only  user.  Tool  commands  from  other  users  are  rejected  with  a  warning  message 
sent  to  their  control  window  W„. 

In  addition  to  the  “Token  Control  Commands"  discussed  earlier,  the  following 
“Session  Control  Commands”  are  available  for  participants  to  interact  with  the 
session  process  P*: 

ESC-END :  to  end  the  session  by  closing  files  and  communications  chan¬ 
nels. 

ESC-STAT:  to  display  information  about  the  session,  such  as:  who  are 
the  participants,  the  objects  in  the  workspace,  when  the  session  has 
started,  etc. 

The  control  window  We  can  also  be  used  for  conversation  between  users.  Any  line 
typed  in  a  control  window  that  does  not  start  with  CTRL  or  ESC  characters  will 
appear  on  all  other  We  windows  preceded  by  the  name  of  the  writer. 
Interprocess  Communications 

Communication  between  processes,  e.g.  between  Pu  and  P*,  is  based  on  the 
4.3  BSD  stream  sockets  in  the  inet  domain}®.  This  provides  us  with  a  reliable, 
bidirectional  virtual  circuit  connection  between  these  unrelated  processes  running 
at  the  same  or  at  different  machines  of  the  network.  For  a  complete  description 
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of  Berkeley  UNIX  Interprocess  Communications  facilities,  see  Reference  10  and 
for  an  introduction  see  Reference  11.  In  our  implementation,  process  P*  creates 
a  socket ,  bind  it  to  a  port  and  listen  for  connections  to  be  made  by  processes  Pu. 
In  turn,  each  process  Pu  creates  a  socket,  bind  to  port  and  listen  for  connection 
to  be  made  by  process  Pc  in  the  same  machine. 

Processes  use  the  SELECT  system  call  to  multiplex  input  from  several  sources^. 
For  example,  process  Pu  need  to  monitor  the  input  from  the  socket  connecting  it 
to  process  Pc,  the  standard  input  from  window  Wt,  the  socket  connecting  it  to  pro¬ 
cess  P*  and,  in  case  of  replicated  model,  the  output  from  the  tool  process.  Here 
we  should  mention  that  many  tools  will  not  function  properly  without  a  terminal 
for  stdin  and  stdout,  and  in  order  to  let  these  tools  read  from  and  write  to  other 
process  rather  than  a  terminal,  a  “pseudo  terminal”  device  is  used  between  the 
tool  and  these  processes For  example,  we  have  used  a  pseudo  terminal  between 
P*  and  the  tool  in  the  central  model,  and  between  Pu  and  the  tool  in  the  replicated 
model. 

Frame  Types  and  Processing 

Since  the  virtual  circuit  between  process  Pu  and  P*  will  carry  messages  from 
different  sources,  messages  are  packaged  in  frames  of  the  format: 


TYPE  LENGTH  DATA 


Frames  are  of  the  following  types: 


token:  for  token  control,  such  as  “get  token”  etc. 
session:  for  session  control,  such  as  “end  session”  etc. 


chat:  for  conversation  messages  between  participants, 
tool:  for  input  to  or  output  from  the  tool. 

Frame  processing  in  Pu  :  Frames  are  processed  in  Pu  as  follows: 

1.  if  the  user  has  the  token,  the  input  typed  in  window  Wt  is  sent  to  P*  in  a 
tool  type  frames. 

2.  data  received  from  Pe  is  processed  according  to  the  following  cases: 

•  data  starting  with  CTRL  character  is  interpreted  and  a  token  type  frames 
is  sent  to  P*  and  Pu  will  change  its  state  accordingly. 

•  data  starting  with  ESC  character  is  checked  and  sent  to  P*  in  a  session 
type  frames. 

•  any  other  data  is  sent  to  P*  in  a  chat  type  frames. 

3.  data  received  from  P*  is  acted  upon  as  follows: 

•  token  type  frames  is  interpreted  and  a  message  is  sent  to  process  Pe 
for  display  in  window  Wc.  Pu  will  change  its  state  accordingly. 

•  data  in  chat  type  frames  is  sent  to  Pe  for  display  in  window  We. 

•  session  type  frames  is  interpreted  and  cause  an  appropriate  actions, 
e.g,  terminate  a  process. 

•  data  in  tool  type  frames  is  processed  based  on  the  following  two  cases: 

For  replicated  model:  forward  to  the  local  tool  process. 

For  central  model:  display  in  the  tool  window  Wt. 


Frame  processing  in  P*  :  Frames  are  processed  in  P*  as  follows: 


1.  token  type  frames  received  from  Pu  are  interpreted  and  handled  according 
to  the  token  management  protocol  described  earlier. 

2.  Received  frames  of  type  chat  is  forwarded  to  every  Pu  process,  except  the 
one  it  has  come  from. 

3.  tool  type  frames  are  processed  according  to  the  following  cases: 

•  For  replicated  model:  Broadcast  the  received  frames  to  all  Pu  processes, 

•  For  single  model:  Forward  the  data  to  the  tool  process.  The  output 
from  the  tool  process  is  sent  to  all  Pu  processes  in  tool  type  frames. 

4.  session  type  frames  are  processed  based  on  its  meaning,  for  example,  for  an 
end  of  session  message,  various  housekeeping  operations  are  performed. 

Source  Code 

The  system  implemented  consists  of  three  main  programs: 

-  session  server  (P*):  771  lines  of  C  code. 

-  user  agent  (Pu):  796  lines  of  C  code. 

-  chat  (Pe):  185  lines  of  C  code. 

In  addition,  the  common  declarations  and  subroutines  are  293  lines  of  C  code. 
Write  to  the  authors  for  a  copy  of  the  source. 
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CONCLUSIONS,  FUTURE  GOALS 


A  simple  remotely  shared  workspace  system  has  been  implemented  using  the  UNIX 
interprocess  communication  primitives.  There  appear  to  be  three  major  directions 
for  research  that  promise  to  make  collaborative  teamwork  a  more  effective  and 
widely  used  tool  in  the  future: 

1.  Human  factors  studies  as  to  what  features  and  functions  are  valued  and 
actually  used  by  different  users  working  on  different  tasks.  For  example, 
insisting  that  all  users  work  on  the  same,  identical,  text  imposes  severe  syn¬ 
chronization  constraints  that  may  slow  down  the  work  unnecessarily.  When 
users  are  happy  with  the  model  that  they  work  on  different  versions  of  the 
same  object,  versions  that  need  not  be  identical  at  all  times,  less  constraining 
implementations  become  possible. 

2.  Studies  of  concurrency,  consistency  and  synchronization  that  are  particularly 
suited  to  supporting  real-time  interaction  among  several  people.  Most  of  the 
concepts  and  techniques  known  today  were  developed  in  response  to  prob¬ 
lems  of  machine-machine  interaction  or  human-machine  interaction.  It  is 
conceivable  that  novel  synchronization  problems  and  techniques  will  arise  in 
the  context  of  human-human  interaction  via  the  intermediary  of  a  machine. 

3.  The  implementation  of  remotely  shared  graphics  workspaces.  This  raises 
problems  of  dealing  with  a  greater  variety  of  interactive  I/O  devices  that 
tend  to  differ  from  machine  to  machine. 
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Fig.  1:  General  view  of  the  system 
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Fig.  4:  Token  control  states  for  user  agent  process 
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